Conventional standalone network probes perform monitoring functions on Internet traffic, and tap into the communication line via a splitter or as an in-line device. The functions typically involve performing some operation on data, inside packets or frames, which is passing through a particular point in the network. Typical functions are, for example, filtering of data, capturing data, forwarding captured data, and summarizing data. Unfortunately, existing probes working as standalone devices configurable to gather data of different types in different arrangements are expensive and require a footprint usually the size of a laptop. Probes that are part of an interface converter or part of a switch or router line card have small footprints, but they have limitations because they are very specific in nature. Thus, when trying to use a probe in a confined space it is necessary to limit the functions that the probe provides in order to use a small footprint probe.
With reference to FIG. 1, PacketPortal™ is a software platform that uses passive, inline intelligent packet director (IPD) transceivers or SFProbes 2, to selectively copy and forward packets from an Ethernet network to a target application. Due to the IPD's form factor, e.g. SFP, they can be affordably distributed where traditional probes are not practical, which enables network operators and managers to access packets and data at any point in the network where optical SFPs are used.
The SFProbe 2 is an inline device, which does not require a separate network connection to deliver captured packets. Instead, the SFProbes take advantage of inter-packet gaps and unused bandwidth in a network when messages or test results have to be sent, as disclosed in U.S. Pat. No. 7,948,974 issued May 24, 2011 to Ilnicki et al, and U.S. Pat. No. 8,009,557 issued Aug. 30, 2011 to Curran-Gray et al., which are incorporated herein by reference. When an idle period is detected, a results packet is inserted into the network for routing back to the system and subsequently the destination application or tools. Accordingly, no network packets are dropped while passing through the SFProbes 2.
The PacketPortal solution examines packets at full-duplex line-rate speeds, empowering the IPD to identify packets of interest that are then copied from the network, accurately time-stamped, encapsulated into a results packet, and inserted back into the network for routing to the targeted application—all without causing loss or disruption to the original flows, as disclosed for example in U.S. Pat. No. 7,894,356, issued Feb. 22, 2011 to Mottishaw et al., which is incorporated herein by reference.
A System Manager 4 provides user management and system access through an easy-to-use, web-based graphical user interface (GUI) 5 that users can access through any compliant browser. The intuitive user interface of the System Manager 4 enables quick easy access to the features, functionality, and management of the entire system.
A Packet Routing Engine (PRE) 6 provides scalable management and control of the SFProbes 2 across the network. Currently each PRE 6 can manage and control up to 500 SFProbes 2; however, future PRE 6 will be able to support thousands of SFProbes 2. Each PRE 6 maintains network connections, state, time synchronization, encryption, and discovery, and they route captured result packets for the SFProbes 2 in their domain. Decoupling the functions of the PRE 6 from those of the central System Manager 4 lets a PacketPortal system scale to sizes never before conceived of for packet-access solutions. PRE's 6 may be synchronized with a global time source, such as a global positioning system (GPS), network time protocol (NTP), IEEE 1588 master clock, as disclosed for example in U.S. Pat. No. 7,573,914 issued Aug. 11, 2009, and U.S. Pat. No. 7,689,854 issued Mar. 30, 2010 both in the name of Ilnicki et al., which are incorporated herein by reference.
To simplify data and packet acquisition, every SFProbe 2 incorporates a protocol header parser (PHP) that automatically identifies most major protocols over virtually any network encapsulation. The PHP works in conjunction with four programmable filter banks, which may be activated in every SFProbe 2. Each filter bank may hold up to eight bidirectional independent filter patterns that define the network traffic to be captured and forwarded. Users can set up simple or complex filters using the GUI 5 from the System Manager 4, as disclosed for example in U.S. Pat. No. 7,760,663 issued Jul. 20, 2010 to Ilnicki et al, which is incorporated herein by reference.
A Packet Delivery Gateway (PDG) 8 enables one or more applications, e.g. analysis application 9a or analysis probe 9b, to connect to the PacketPortal system and receive time-aligned packets, as if they were locally connected to a monitor port or tap at the remote location. The PDG uses captured timestamps and sequence numbers from the SFProbes 2 to play aggregated streams out a monitor port. The streams maintain proper sequencing and inter-packet timing that represents what the packets experienced while passing through the remote network port. PDG's 8 can feed packets to any device or application that would normally connect to a tap, SPAN port, aggregator, mirror port or equivalent technology. The PDG 8 enables applications to reside in central locations instead of remote locations, where it may not be economically practical to deploy. Accordingly, the PDG 8 provides the ability to utilize legacy and even future probes and test systems with the PacketPortal system.
A virtual network interface card 10 (VNIC) is a software component that emulates a physical network interface card (NIC) driver and enables any Ethernet-based software application to receive feeds from a PacketPortal system via a NIC interface. The VNIC receives Packet Portal feeds, removes the transport headers and metadata to reveal the network traffic, and retransmits the original packets to the PC's network stack. The traffic is replayed using the original capture timestamps and sequence numbers to accurately represent the traffic as it was captured at the remote element. The replay may be configured to output on a specific transmission control protocol (TCP) or user datagram protocol (UDP) port from the PRE 6 to the VNIC 10. The VNIC 10 can also read captured network data files in the packet capture (PCAP) format and replay them similarly to how live traffic is processed through the PacketPortal system.
The SFProbes 2 can be located in various locations connected to a core IP network 11, such as nodes 12, switches 13, routers 14, data receivers and transmitters 15, and any other access equipment 16, e.g. DSLAM, CMTS, OLT etc.
High complexity software applications utilizing many threads of execution are difficult to analyze and debug. As the application is scaled to process more and more work, this analysis and debugging becomes much more difficult. Logging that contains information that can provide a picture of the complex interactions of all execution threads over time is needed. Application performance tuning requires that the logging is also fast enough to have very little impact on overall execution performance to allow analysis of the application running at speed. Logging may also contain information that the customer or someone trying to reverse-engineer the application should not see. The present invention logs a rich set of information in a binary record format that is obfuscated and so compact that it is very fast to write.
An object of the present invention is to overcome the shortcomings of the prior art by providing a high speed logging system that stores compacted log records in a first memory buffer in random access memory (RAM).